1. Field of Invention
This invention relates to the field of configuration management systems and methods for managing development of a software project. More particularly, embodiments of the present invention relate to systems and methods for enabling users of a software configuration management (SCM) application to automate the execution of one or more software analysis processes in response to events generated by a software configuration management application without requiring the users to have knowledge of how the SCM application or the software analysis process operates.
2. Discussion of Related Art
A programmable computer by itself performs few useful functions until it is provided with, and executes, computer programs—software—designed to carry out useful functions (such as, but not limited to, database, word processing and spreadsheet operations). The programs that provide this functionality are often called “applications.” Application programs generally are not complete in themselves, and rely on certain commonly-needed operations provided by basic “platform” software called an operating system.
Developing computer programs such as operating systems and software applications and products (which activity includes both initial development and later modifying or adding to the initial development) often requires the coordinated efforts of many developers (e.g., software programmers). This coordinated effort is referred to herein as a “software development effort” or “development effort,” and a body of work (e.g., one or more software products, including software applications) being developed by the effort is referred to as a “software development project,” “software project,” or “project.” A software development effort may comprise one or more software projects. At any given time, as part of a software development effort, multiple developers may be working on different software components of a software development project and/or different versions of these software components (e.g., for different users or situations). Thus, there may be multiple concurrent software development efforts ongoing, at least some of which use or involve the modification of common software components, including different versions of those software components and sometimes multiple versions of components.
Frequently, a software development project may involve several, or even dozens or more, of developers working on (e.g., writing, debugging, testing, etc.) a few to even hundreds of software components that are a part of the software project. Managing one or to more software development projects and the concurrent development of these different software components and versions is commonly referred to as software configuration management (SCM). Computers or computer systems running SCM software applications (i.e., programs) assist developers and project managers in the complex task of managing a software development project, including maintaining coherency between different software components and versions. (Hereafter, the terms “SCM software application” or “SCM application” may be used to refer to a software program able to be executed on a computer or computer system, or to such computers or computer systems that are executing or are adapted to execute an SCM application. The presence of an appropriate underlying operating system is assumed, though it certainly is possible to integrate operating systems and application program features in one product.)
While some SCM applications may be implemented that have a range of features and functionality additional to managing software development, as used herein an “SCM application” is a software application (i.e., one or more programs) that manages and stores information relating to configurations of software components used to produce a software product. An application that includes this functionality as well as additional functionality is an application that incorporates and includes an SCM application. Accordingly, some functionality of an application that incorporates and includes an SCM application, and functionality of other applications, is “external” to the SCM application in that it is not a part of the SCM application.
An SCM application may be one of a variety of applications and processes that may be used during a software development effort. These other applications and processes, external to the SCM application, may include software analysis processes that perform various tests on software development projects to determine whether the software development project has one or more characteristics or meets one or more standards. A “build” process is one example of such a software analysis process. A developer of a software project may execute a build process on the software project to determine whether the software project is capable of being “built” from a developer's source code into computer-executable software code, and thus determine whether the software project contains any structural programming errors (e.g., calls to non-existent code).
Software analysis processes, like build processes, typically are implemented externally to an SCM application as “external software analysis processes” that are carried out by “external applications.” Such software analysis processes often have one or more to interfaces by which a user may trigger the software analysis processes to execute. In the case of a build process, a user may configure a version of a software development project using an SCM application, then turn to an external software analysis process (i.e., a process external to the SCM application) to carry out the build process. Following execution, the external process may then return a result to the user via the interface of the application, the result including an indication of whether the software project was able to be built and whether any programming errors were detected. If the build process does contain programming errors, the user may then return to the SCM application to identify and fix those errors using the software configuration functionality of the SCM application.
To execute a software analysis process, the user may configure the process with information regarding a version of a software project, using information maintained by the SCM application. Many conventional SCM applications do not store information regarding a version of a software project, but rather store information relating to individual components that are a part of the software project; in such systems, information regarding the version is maintained separately or by the user. Accordingly, the input information regarding the version of the software project may be a listing of software components (e.g., individual source code files) included in the version of the software project. To do this, the user may use a user interface of the software analysis process to locate a store of software components, maintained by the SCM application, included in various versions of software projects managed by the SCM application, and select the software components relating to the version of the software project the user would like analyzed. Once the components are selected, the user may then trigger the process via the interface and wait for the results. This technique is manual, and requires user intervention at each step to initialize and execute the software analysis process.
In some cases, users of SCM applications, including developers, have added functionality to an SCM application to offer limited interaction between the SCM application and software analysis processes external to the SCM application, to provide some automation of these processes. This automation may be linked to occurrence of events in the SCM application. For example, when a user makes a change to a version of a software project (e.g., by editing some code), an event may be generated that triggers a build process to determine if the version has any programming errors following the change. A user of an SCM application, wishing to automate a process to be performed on a version on occurrence of an event, may generate a script (e.g., a Perl script) in the SCM application that monitors the version for to occurrence of one or more events and, in response to the event, passes information regarding the version to the software analysis process. The information regarding the version may be, for example, a listing of software components included in the version, such as the list selected by the user in the manual process. The user may also develop a script for the software analysis process that waits for the information and performs the process upon receipt. In conventional systems, for each event and each version to be monitored and each software analysis process to be automated, a new script will be generated or an existing script modified to include additional information regarding the new event/process.
Generation of automation scripts, however, is an intensive process that is costly in time and requires a great deal of knowledge of the SCM application as well as the external software analysis process(es) to be automated. For example, to generate a script to automate a build process, a user may require knowledge of the format of data maintained by the SCM application and the manner in which it is edited. This may be necessary because the script will have to detect the occurrence of events associated with the editing of the data, and then retrieve the data and transmit it to the external software analysis application. The user may further require information about the data formats of the software analysis process, such that the script can provide the information regarding the version of the software project in a way that the software analysis process can operate on it. Further, the user may have to understand how the software analysis process operates and how to provide it with information and trigger it to execute. For example, if a build process executes by carrying out builds specified by a configuration file according to schedules contained within the configuration file, then the script (and its author) will have to know how to write information to the configuration file, in the format of the configuration file, regarding the version of the software project and the build desired. As another example, if the build process executes by accepting initial configuration information regarding a build to be performed on occurrence of an event, and then periodically polling the SCM application to determine whether the event has occurred, the user will have to know how to configure initially the software analysis process and then generate the script to provide the information in a way that the software analysis process can detect it during the polling process.
In short, a great deal of knowledge is required of SCM application users to generate scripts to automate software analysis processes, and generating the scripts is intensive and time-consuming. Accordingly, many users are deterred from generating scripts to automate these processes and instead manually perform tasks using software analysis processes. In to some cases, a software development effort may even employ a person working as a dedicated script-generator, such that these tasks can be automated using scripts, but individual developers do not need to have the required information to generate the script. Instead, the developers request that the script-generator write the script to automate the process. In such cases, however, generation of the script may be delayed until the script-generator is able to work on it, and thus a developer may be deterred from requesting scripts in many circumstances and only request scripts when absolutely necessary or when the script is not important and generation can be postponed.
In other cases, rather than generate a script—or request that a script be developed, if the effort is employing a script-generator—the developer may use the software analysis process directly via the interface. Doing so requires, of course, that the developer be knowledgeable about how to use the software analysis process via the interface. If a developer does not know how to use the software analysis process, then the developer may be further deterred from using the software analysis process, and thus may not use the analysis process at all; or the developer must divert a significant amount of time from software development, to learn how to use the software analysis process. This inefficiency may be repeated over a number of developers.
Thus, in some situations, developers of a software development effort may not even use some software analysis processes available to them, because of the various obstacles to their use. Software analysis processes, however, may provide useful information to developers of a software project that may help them improve the quality of the software project. For example, a software analysis process may, via a build process, discover programming bugs in the version that the developer can solve; or may, via a code coverage process, discover portions of code that a developer has forgotten to draft, such as when the developer has only written code to handle a “true” case of a true-false condition and has forgotten to write code to handle the “false” case, or such a process may, via a memory check process, discover memory errors that may cause a computer executing a software product of a software project to run slowly, among others.
It is advantageous for a developer to use these software analysis processes, and, in view of the above, there is need for a simplified manner by which the developer can use these software analysis processes without requiring knowledge on how an SCM application or a particular software analysis process operates.